1. Field of the Invention
The present invention relates to computer networks and more particularly to dynamically responding to non-network events at a network device in a computer network.
2. Background Information
A computer network is a geographically distributed collection of nodes (or “network devices”) interconnected by communication links and segments for transporting data between end nodes, such as personal computers and workstations. Many types of networks are available, with the types ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect the nodes over dedicated private communications links located in the same general physical location, such as a building or campus. WANs, on the other hand, typically connect geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines, optical lightpaths, synchronous optical networks (SONET), or synchronous digital hierarchy (SDH) links. The Internet is an example of a WAN that connects disparate networks throughout the world, providing global communication between nodes on various networks. The nodes typically communicate over the network by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). In this context, a protocol consists of a set of rules defining how the nodes interact with each other. Computer networks may be further interconnected by an intermediate network node, such as a router, to extend the effective “size” of each network.
Computer networks and the information transmitted over the networks are generally subject to one or more policies based on network events. A policy, as used herein, refers to a set of rules defining one or more actions that are to be taken in response to one or more events. A network event or network-based event is any event that occurs within the infrastructure and/or data flow of the network, e.g., resulting in topology changes, changes in traffic flow, etc. For example, various network events may include, inter alia, traffic congestion, addition/loss of a link/node, updates to routes within the network, Denial of Service (DoS) attacks, etc. These events are typically discovered by the network devices through techniques that will be understood by those skilled in the art, such as, e.g., various routing protocols, traffic monitoring, etc. Conventional responses to network events may include, for example, redirecting traffic routes (e.g., around failures, congestion, etc.), shutting down a port, applying access control lists (ACLs), etc. Policies regarding network-based events, therefore, are conventionally configured to respond to network events with network-based actions.
A “non-network event” or a “physical event” is any event that occurs within the physical realm/environment, i.e., not within the network infrastructure/data flow. For example, various non-network events may include, inter alia, fire, flood, physical user presence, etc. These events may be detected using known physical sensors, such as smoke detectors, motion sensors, video surveillance equipment, etc. These events detected by the sensors are generally sent to a central monitoring/control system, e.g., a proprietary alarm system, security center, etc. Once the monitoring/control system receives notice of a physical event, one or more physical-based policies may be applied depending upon the particular event. For instance, detection of smoke or fire may result in an automated fire alarm sounding within a particular building. Alternatively, a motion sensor may indicate to a security official that a security breach may be occurring, and the security official may manually determine the cause of the alarm, e.g., by physically inspecting the premises. Policies regarding non-network-based events, therefore, are conventionally configured to respond to non-network events with non-network-based actions. Notably, a physical event directly affecting the network (e.g., physical destruction of a server) results in a network-based event (loss of a node), as will be understood by those skilled in the art.
Today, some physical sensors and monitoring/control systems have begun to offer the capability to attach to computer networks for communication purposes. For instance, rather than providing a set of system-specific or proprietary communication lines within a building, many physical sensor systems are connected to the computer network already in place. As such, the sensors (or designated sensor translators) translate the raw data obtained from the physical sensors and create packets or frames of information suitable for transmission over the computer network. These packets/frames may then be transmitted to the monitoring/control system for processing and reaction. The monitoring/control system may then dynamically respond to the physical (non-network) events, or a system administrator may manually respond.
Currently, network devices, i.e., conventional network devices (routers, servers, etc.) other than the attached sensors and monitoring/control systems, are not configured to respond to non-network events. Generally, the network devices are unaware of its physical surroundings. For example, a router may not know that a building is on fire, but will only detect a loss of communication to one or more nodes within that building after the fire has severed connections or destroyed nodes. At this point, if the network device is located within the same burning building, it may be too late to take any necessary actions. For instance, once a fire in the building is detected, a system administrator may instruct a server or data center to start storing its data at a remote (off-site) location, thus “backing up” the data. The manual intervention of administrators/operators to instruct network devices to change their network operations may be unreliable (assuming they are available and/or notice the physical event) and slow. Importantly, if the only access to a network device is to physically be located with the device, the administrators/operators may be put at risk while attempting to change the network operations (e.g., running into a burning building).
Also, network devices are not configured to control physical parameters within the physical environment (i.e., other than internal systems, e.g., disk drives, tape drives, fans, coolers, etc., as will be understood by those skilled in the art). In the event of a fire, for example, network devices (such as routers, servers, etc.) are unable to take any physical action, such as closing doors, initiating fire suppression, signaling alarms, etc., to protect themselves, other devices, or even people from danger. As it stands, a network administrator must manually control the physical parameters or manually direct one or more network-attached physical control devices (e.g., a sprinkler system attached to the monitoring/control system) to take action.
In particular, time delays may be associated with transmission of a conventional warning message to a control/monitor station, in addition to the control/monitor station reacting, in further addition to the possible transmission of a reaction back to the area initially causing the physical event. These time delays may occasionally be sufficiently lengthy to prevent critical early responsive action within the network, e.g., preventative protection measures.
Further, because the network device is unaware of the non-network events, it is unable to respond in other ways not directed to protection/self-preservation of the network (network operation and/or physical preservation). For example, the network device is unable to transmit warning messages or other useful information to other network devices or people in response to non-network events, e.g., when the devices/people may be in possible danger. Particularly, the time delays associated with transmitting a message from a control/monitor station may be unacceptable for this information, assuming the message could reach the devices/people (such as, for example, where external communications are severed to devices within a building).
There remains a need, therefore, for a system and method to have network devices efficiently and dynamically respond to non-network (physical) events. There also remains a need for network devices to dynamically control physical parameters in response to non-network and/or network-based events.